The technology a business buys today may still be handling sensitive information when cryptographic requirements change. A payment platform, identity service or industrial device can remain in use for years. That creates a planning problem for companies preparing for quantum computing: the date of the future threat is uncertain, but the time needed to replace vulnerable systems is already an operational concern.
Post-quantum cryptography uses mathematical techniques designed to resist attacks from both conventional computers and sufficiently capable future quantum computers. For businesses, preparing for it means understanding where cryptography is used, which information needs lasting protection and how suppliers intend to support migration. The commercial objective is an orderly transition that preserves service reliability while addressing the relevant security risks.
Standards have turned preparation into practical work
In August 2024, the US National Institute of Standards and Technology finalised three principal post-quantum standards. They cover a mechanism for establishing shared cryptographic secrets and two approaches to digital signatures. These functions serve different purposes, so replacing one does not automatically protect every aspect of a system.
Key establishment helps parties agree the secret used to protect communications. Digital signatures help verify authenticity and detect changes to signed information. A business might encounter both in the same customer service, with additional dependencies in certificates, software updates and the devices supporting it.
The standards provide an important foundation, but an approved algorithm is only part of a working implementation. Software libraries, applications and network components must use it correctly and interoperate with one another. Businesses therefore need evidence about actual products and configurations, rather than treating a general statement of support as proof that an entire service has migrated.
This distinction affects purchasing decisions. A supplier may offer a post-quantum capability in one product version while other components still depend on older mechanisms. Procurement teams need to connect the claim to the service being purchased and the specific security function it covers.
Long lived information changes the timetable
Some information loses its sensitivity quickly. Other records, including commercial research, personal information and long-term contracts, may remain valuable for many years. The required confidentiality period helps determine which systems deserve early attention.
A joint CISA, NIST and NSA resource published in 2023 warned that information could be collected now for possible decryption with future quantum capabilities. This is often described as harvest now, decrypt later. It concerns exposure over time, rather than evidence that current quantum computers can routinely defeat deployed public-key security.
That distinction prevents two errors. Businesses should avoid presenting an uncertain technological timetable as a confirmed deadline for a cyberattack. They should also avoid assuming that uncertainty justifies postponing every preparatory task. An inventory and a supplier discussion can be useful before a company is ready to approve production changes.
Data retention deserves attention alongside encryption. Keeping information longer than the business needs increases the period for which it must remain protected. A review of retention and access can reduce unnecessary exposure, although it does not replace migration where vulnerable cryptography remains necessary.
Discovery requires more than a server list
Cryptographic functions are embedded across business systems. They can support website connections, remote access, software signing and authentication between applications. Some are directly managed by the company; others are inside cloud services or supplied devices.
An equipment inventory helps identify where to look, but it may not reveal the algorithms or protocols in use. A useful discovery exercise connects a business service to its applications, underlying components and external dependencies. It also records who can answer technical questions and who has authority to approve a change.
The information needs to remain current. A migration plan based on a one-off scan can become inaccurate as teams introduce services or retire old ones. Integrating cryptographic discovery with existing asset and change management gives the organisation a way to keep the evidence useful.
There will be gaps. Older systems may lack documentation, and suppliers may be unable to provide a complete answer immediately. Recording those gaps, their significance and the next action is more credible than reporting an apparently complete inventory built on assumptions.
Priorities should follow business exposure
An organisation does not need to give every system the same migration date. The sensitivity of the information, the importance of the service and the difficulty of replacement all affect priority. A long-lived device with limited upgrade options presents a different planning challenge from a frequently updated application.
The UK National Cyber Security Centre migration guidance published in March 2025 recommends discovery and initial planning by 2028, high-priority activities by 2031 and completion of migration by 2035. These are UK guidance milestones, not a universal statutory timetable for every business or jurisdiction.
Their practical value is the separation of preparation from deployment. A company can identify dependencies and budget requirements before every product is ready. It can then sequence the highest-priority work while continuing to refine its plan as technical options develop.
For financial institutions, prioritisation may involve customer confidentiality and the authenticity of payment instructions. A manufacturer may need to consider software updates for equipment expected to operate for another decade. The relevant assessment follows the business process, rather than treating an organisation’s industry label as a complete risk measure.
Supplier claims need a defined scope
A useful supplier response explains the affected products, supported versions and expected route to upgrade. It distinguishes available functionality from planned development. It also identifies responsibilities that remain with the customer, such as changing certificates, updating applications or replacing unsupported equipment.
Contracts can create opportunities to improve that visibility. During renewals, businesses can ask how cryptographic changes will be delivered, what support is included and how compatibility will be demonstrated. A broad promise to remain secure is less informative than a documented process for maintaining the specific service.
This does not mean customers can demand certainty about every future standard. Product development and protocol work may still be evolving. The reasonable objective is to identify which decisions can be made now, which depend on external developments and how those dependencies will be monitored.
Commercial concentration can also affect migration. If several important services depend on one supplier’s cryptographic library, its release schedule may constrain several projects at once. Understanding that shared dependency helps management plan capacity and avoid contradictory assumptions across departments.
Testing has to follow the complete transaction
An algorithm can work correctly in isolation while a business transaction fails elsewhere. Larger signatures or different processing requirements can affect message handling, storage and device performance. Applications may also behave differently when they encounter a system that has not yet been upgraded.
The BIS Innovation Hub report on Project Leap phase 2, published in December 2025, describes testing post-quantum cryptography in an operational payment system. The experiment involved changes to multiple components and identified performance and interoperability considerations. It was a specific experiment, rather than certification that all payment systems were ready for migration.
For businesses, the lesson is to test an entire process with representative conditions. A laboratory demonstration involving a small number of messages does not establish how the service will behave under peak demand or during a recovery event.
Testing should also examine failure handling. If one component rejects an updated signature or cannot negotiate a supported connection, teams need to know what happens next. A fallback that quietly returns the service to an unsuitable security configuration can undermine the purpose of the change.
Protocol guidance continues to develop
The NCSC updated its guidance on post-quantum configurations for TLS on 15 October 2026. TLS is a protocol used to protect data in transit. The update illustrates how migration depends on protocol implementations as well as algorithm standards, and why businesses need to consult current technical guidance when making deployment decisions.
Technical choices should be assessed by qualified specialists in the context of the intended service. Combining traditional and post-quantum mechanisms, for example, creates implementation and compatibility questions that a product label cannot resolve. General management needs enough information to govern the decision without selecting cryptographic parameters by intuition.
Different security functions may become available at different times. A connection can gain a new key-establishment mechanism while its authentication arrangements follow a separate migration path. Progress reporting should state which function has changed so that a partial improvement is not mistaken for complete protection.
Existing security work remains necessary
Post-quantum migration addresses a particular class of future cryptographic exposure. It does not prevent compromised passwords, poorly controlled access or exploitation of unpatched software. Businesses still need to maintain the controls relevant to those risks while carrying out the transition.
The NIST National Cybersecurity Center of Excellence migration resources address practical questions about discovery, interoperability and migration. Their focus supports treating the transition as a managed programme with multiple dependencies, rather than a purchase that can be completed by selecting a single security product.
Some preparatory work can improve current operations. Identifying unsupported software, documenting certificate ownership or clarifying supplier responsibilities can remove uncertainty that already affects resilience. Those benefits should be described specifically, without assuming that every migration activity produces an immediate financial return.
Maintaining proportion is essential. A rushed replacement can introduce downtime or configuration errors. A carefully sequenced programme can address priority exposure while keeping normal security maintenance and operational controls in place.
Budgeting should include people and integration
Licence and hardware costs may be easier to identify than engineering time, testing and coordination. Yet these activities can determine the duration of the programme. Shared teams may be required for application changes, network configuration and supplier assurance across several services.
An illustrative project shows the issue. Upgrading a gateway could be inexpensive relative to the work needed to test every connected application and arrange a maintenance window. If the business budgets only for the gateway, it understates the resources required to put the capability into reliable use.
Replacement cycles can offer opportunities to avoid duplicated expenditure. A company purchasing a long-lived platform can assess its migration options before committing. Where an older system is already scheduled for retirement, the plan can consider whether to upgrade it or move the relevant business process to its replacement sooner.
These choices remain conditional on risk and feasibility. A planned retirement is not enough if the timetable is uncertain and the system holds highly sensitive information. Finance and technology teams need a shared view of those assumptions before counting future replacements as completed mitigation.
Evidence provides a better measure of progress
The number of systems labelled ready can conceal substantial differences in coverage. Better reporting distinguishes completed discovery, tested upgrades and unresolved dependencies. It identifies business-critical services separately so that minor successes do not obscure a significant gap.
Management also needs to understand the quality of the evidence. A supplier statement, an internal test and an observed production deployment support different conclusions. Recording the basis for each status makes the overall programme more auditable and helps direct technical review towards uncertain areas.
Common questions
Does post-quantum cryptography require a quantum computer? No. These cryptographic techniques are designed to run on conventional systems while resisting relevant attacks from future quantum computers.
Does adopting one standard protect an entire organisation? No. Protection depends on correct implementation, the security functions involved and the systems connected to them. Key establishment and digital signatures need separate consideration.
Why prepare before the timing of the threat is known? Discovery, supplier coordination and replacement can take years. Long-lived sensitive information and equipment can make early planning useful even when the date of a cryptographically relevant quantum computer remains uncertain.
The strongest business case for preparation is a credible transition plan. Companies that understand their cryptographic dependencies can make better purchasing and replacement decisions, identify the work requiring specialist support and test changes before they affect important services. That provides a practical response to uncertainty without relying on a precise forecast of quantum computing progress.
References
1. NIST releases its first three finalised post quantum cryptography standards August 2024
2. CISA NIST and NSA quantum readiness recommendations August 2023
3. NCSC Timelines for migration to post quantum cryptography March 2025
https://www.ncsc.gov.uk/guidance/pqc-migration-timelines
4. BIS Innovation Hub Project Leap phase 2 report December 2025
https://www.bis.org/publications/project-leap-phase-2-quantum-proofing-payment-systems
5. NCSC Post quantum updates to TLS guidance October 2026
https://www.ncsc.gov.uk/blogs/post-quantum-updates-to-our-tls-guidance
6. NIST NCCoE Migration to post quantum cryptography resources and frequently asked questions
https://pages.nist.gov/nccoe-migration-post-quantum-cryptography/